home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-atm-classic-ip-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
27KB
|
676 lines
Network Working Group Mark Laubach
Request for Comments: DRAFT Hewlett-Packard Laboratories
Expires January 5, 1994 July 5, 1993
Classical IP and ARP over ATM
Status of this Memo
This document is an internet draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". Please check the lid-abstracts.txt
listing contained in the internet-drafts shadow directories on
nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or
munnari.oz.au to learn the current status of any Internet Draft.
1. Abstract
This memo describes an initial application of classical IP and ARP in
an ATM network environment configured as a Logical IP Subnetwork
(LIS) as described below and in [1]. This memo does not preclude the
subsequent development of ATM technology into areas other than an
LIS; specifically, as single ATM networks grow to replace many
ethernet local LAN segments and as these networks become globally
connected, the application of IP and ARP will be treated differently.
This document considers only the application of ATM a as a direct
replacement for the "wires" and local LAN segments connecting IP
end-stations and routers. Issues raised by MAC level bridging are
beyond the scope of this paper.
3. Acknowledgment
This memo could not have come into being without the critical review
from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and
Bryan Lyles, Steve Deering, and Berry Kercheval of XEROX PARC. The
concepts and models presented in [1], written by Dave Piscitello and
Laubach [Page 1]
DRAFT Classical IP and ARP over ATM July 1993
Joseph Lawrence, laid the structural groundwork for this work. This
document could have not been completed without the expertise of the
IP over ATM Working Group of the IETF.
4. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- the item is an absolute requirement
of the specification.
o SHOULD or RECOMMEND -- this item should generally be followed for
all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
5. Introduction
The goal of this specification is to allow compatible and
interoperable implementations for transmitting IP datagrams and ARP
requests and replies over ATM Adaptation Layer 5 (AAL5)[6].
Currently, ATM standards are being defined in the ITU-TSS (formally
CCITT), ANSI and the ATM-FORUM. ITU-TSS and ANSI are defining
standards for public ATM networks. The ATM-FORUM is not a recognized
standards body, however they are addressing the application of ATM in
the local environment and there is substantial public involvement.
It is the intent of this document to follow ITU-TSS standards except
where the ATM-FORUM provides needed functionality.
Initial deployment of ATM provides a LAN segment replacement for
ethernet networks and as wire-replacement for dedicated public
telecommunication lines between IP routers. In the former model,
local IP routers with one or more ATM interfaces will connect islands
of local ATM networks. ATM-FORUM compliant addressing will be used
within these local ATM networks. In the latter model, public ATM
networks will be used to connect IP routers, which in turn may or may
not connect to local ATM networks. Public networks will use ITU-TSS
and ANSI standards for addressing in ATM. ATM-FORUM compliant
addressing cannot be guaranteed in public ATM networks.
The characteristics and features of ATM networks are different than
those found in LAN's:
o ATM provides a virtual circuit switched environment. VC setup may
be done on either a Permanent Virtual Circuit (PVC) or dynamic
Switched Virtual Circuit (SVC) basis. SVC call management
Laubach [Page 2]
DRAFT Classical IP and ARP over ATM July 1993
signalling is performed via Q.93B implementations [7,9].
o Data to be passed by a VC is segmented into 53 octet quantities
called cells (5 octets of ATM header and 48 octets of data). ATM
networks provide very low latency switching, high throughput, and
the ability to multiplex VC's of differing quality of service.
o Each VC carries a type which identifies a specific format for the
exchange of protocol data units (PDU's). These formats are called
ATM Adaptation Layers (AAL's) and are typed from 1 through 5.
AAL5 specifies a packet format with a maximum size of 64K user
data octets. Cells for an AAL5 PDU are transmitted first to last,
the last cell indicating end of PDU. ATM standards guarantee that
on a given VC, cell ordering is preserved end-to-end.
o ATM-FORUM signalling defines point-to-point and point-to-
multipoint addressing [9]. Multicast service addressing is not
yet a conformance requirement of the ATM-FORUM.
o ATM-FORUM local LAN addresses are hardware addresses using the
same format as NSAP's.
This memo describes the initial deployment of ATM within "classical"
IP networks as a direct replacement for local area networks
(ethernets) and for IP links which interconnect routers, either
within or between administrative domains. The "classical" model here
refers to the treatment of the ATM host adapter as a networking
interface to the IP protocol stack.
Characteristics of the classical model are:
o One default maximum MTU size for the network interface,
consistent with current implementations.
o Default LLC/SNAP encapsulation of IP packets, with administrator
allowed reconfiguration.
o IP destinations map to VC's via ARP and route lookups, consistent
with current model.
o ARP's stay within the LIS, current ARP architecture stays the
same.
o One IP subnet used for many hosts/routers. A separate VC is used
for each host/router pair, one subnet is used for all these VC's.
The "global" ATM model is an evolution of the classical model where
the ATM network becomes more fully deployed and globally available.
Laubach [Page 3]
DRAFT Classical IP and ARP over ATM July 1993
In this model, the traditional protocol stack architecture evolves
allowing applications to map directly on VC's (e.g., TCP and UDP
ports map directly onto VC's) and ARP mechanisms are no longer bound
to LIS boundaries as queries and replies may go global. IP will
evolve to take advantage of the network services provided by the
global ATM network.
Characteristics of the global model are:
o MTU size negotiated per VC via ATM signalling, requires MTU size
be separated from interface in protocol stack.
o Encapsulation negotiated per VC via ATM signalling, requires
common signalling to be implemented and globally available.
o Any applications map to VC's, requires changes to TCP/UDP/IP to
allow ports to map directly on to VC's
o ARP's can go global, ARP architecture needs to change to support
a robust global client/server model.
o Differing quality of service (QOS) guarantees will exist on a per
application and per VC basis.
The deployment of ATM into the internet community is beginning and
will take several years to implement. During this period, we expect
deployment to follow traditional IP subnet boundaries for the
following reasons:
o Administrators and managers of IP subnetworks will tend to
initially follow the same models as they currently have deployed.
The mindset of the community will change slowly over time as ATM
increases its coverage and builds its credibility.
o Policy administration practices rely on the security, access,
routing, and filtering capability of IP Internet gateways: i.e.
firewalls. ATM will not be allowed to "back-door" these
mechanisms until ATM provides better management capability than
the existing services and practices.
This memo details the treatment of the classical model of IP and ARP
over ATM. There are those would like to have IP-over-ATM begin by
breaking the classical model - this memo represents the view that we
must walk before we can run. This memo does not preclude the
subsequent evolution of ATM networks as they become more globally
deployed and interconnected and the evolution of TCP and IP to take
advantage of these changes - these will be the subject of future
documents. This memo does not address issues related to transparent
Laubach [Page 4]
DRAFT Classical IP and ARP over ATM July 1993
data link layer interoperability.
6. IP Subnetwork Configuration
This section describes the scenario for an ATM network that is
configured with one or more Logical IP Subnetworks (LIS's). The
scenario considers only directly connected IP hosts or routers
reachable via switched virtual circuits (SVC's).
In the LIS scenario, each separate administrative entity configures
its hosts and routers within a closed logical IP subnetwork. Each LIS
operates and communicates independently of other LIS's over the same
ATM network. Hosts connected to ATM communicate directly to other
hosts within the same LIS. Communication to hosts outside of the
local LIS is provided via an IP router. This router would be a
station attached to the ATM network that may have been configured as
a member of two or more LIS's. This configuration results in a number
of disjoint LIS's operating over the same ATM network. Hosts of
differing IP subnets would communicate via an intermediate router
even though a direct virtual circuit between the two hosts may be
available over the ATM network.
The requirements for IP member stations (hosts, routers) operating in
an ATM LIS configuration are:
o All members have the same IP network/subnet number.
o All stations within an LIS are accessed directly over the ATM
network.
o All stations outside of the LIS are accessed via a router.
o All members of an LIS must have a mechanism for resolving IP
addresses to ATM addresses via ARP [4] when using SVC's.
o All members within a LIS MUST be able to communicate with all
other members in the same LIS; i.e., the topology is fully
meshed. There should be no administrative restrictions at the ATM
level that prevent VC's from operating between all pair of
stations.
The following list identifies a set of ATM specific parameters that
MUST be implemented in each IP station which would connect to the ATM
network. The parameter values MUST be user configurable:
o ATM Hardware Address (atm$ha). The ATM individual address of the
IP station. Each host must be configured to accept datagrams
destined for this address
Laubach [Page 5]
DRAFT Classical IP and ARP over ATM July 1993
o ATM ARP Request Address (atm$arp-req). The ATM hardware address
(point-to-point or multicast) to which ARP requests are to be
sent for the resolution of target protocol addresses to target
hardware addresses for SVC connections. Three cases are
available:
1. atm$arp-req is atm$ha, the local machine ATM hardware address.
The local host may either consult its ARP translation table
directly, or preferably to support ARP queries by loopback
internally or externally via the ATM network. In the case of
an external loopback, a VC is dedicated specifically for ARP
queries and replies. This case is called the "Loopback ARP"
model.
2. atm$arp-req is the ATM hardware unicast address of an
individual ARP server located within the LIS. That server must
have authoritative responsibility for resolving ARP requests
all IP stations within the LIS. The VC's connecting IP
stations to this ARP server are dedicated specifically for ARP
queries and replies. An individual client connects to the ARP
server using a point-to-point (unicast) connection. The
server, upon receiving connections from new clients, will add
the client address to a single point-to-multipoint group.
Queries to the server are received on the unicast VC from the
client. The server responds on the multipoint VC enabling all
clients receive the reply. This case is called the "ARP
Server" model.
3. atm$arp-req is an ATM hardware group (multicast) address. If
the ATM switching fabric supports ATM hardware multicast, then
a well known VC using the ATM group address local to the LIS
is dedicated specifically for broadcast ARP queries and
replies and IP packets sent to the IP broadcast address. The
ARP query/reply service on all IP stations within the LIS MUST
be reachable via this address. This case is called the
"Multicast ARP" model.
It is RECOMMENDED that the ARP Server model be implemented within an
LIS. The use of redundant ARP servers however, reachable via a group
address, is beyond the scope of this document.
The Multicast ARP model is attractive in that it more closely models
the well known ethernet service of which the community has many years
of experience. There are some technical details that need to be
worked out involving the simultaneous transmission of multi-cell AAL5
PDU's from different sources in a multicast environment and the
interleaving of PDU's as seen by the receiver. Multicast ARP
mechanisms should be explored as experience from these experiments
Laubach [Page 6]
DRAFT Classical IP and ARP over ATM July 1993
can contribute directly to the definition of multicast address
services in future ATM-FORUM standards activities. The multicast ARP
model will be more fully detailed in a future document.
ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's
[9].
ARP request and reply formats are discussed in the section on Address
Resolution.
It is RECOMMENDED that routers providing LIS functionality over the
ATM network also support the ability to interconnect differing LIS's.
Routers that wish to provide interconnection of differing LIS's MUST
be able to support multiple sets of these parameters (one set for
each connected LIS) and be able to associate each set of parameters
with a specific IP network/ subnet number. In addition, it is
RECOMMENDED that a router be able to provide this multiple LIS
support with a single physical ATM interface that may have one or
more individual ATM addresses.
7. Packet Format
The default packet format for IP datagrams SHALL be the IEEE 802.2
LLC/SNAP format as described in [2].
This memo recognizes the future development of end-to-end signalling
within ATM that will allow negotiation of encapsulation method on a
per-VC basis. Signalling negotiations are beyond the scope of this
document.
8. MTU Size
The default MTU size for IP stations operating over the ATM network
SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the
maximum ATM AAL5 protocol service unit size will be 9188 octets. In
classical IP subnets, values other than the default can only be used
provided that all stations on the LIS can be configured to use the
non-default value.
The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8
octets, therefore the minimum ATM AAL5 protocol data unit size will
be 584 octets.
This memo recognizes the future development of end-to-end signalling
within ATM that will allow negotiation of MTU size on a per-VC basis.
Signalling negotiations are beyond the scope of this document.
9. Address Resolution
Laubach [Page 7]
DRAFT Classical IP and ARP over ATM July 1993
The dynamic mapping of 32-bit Internet protocol addresses to ATM
hardware addresses within an LIS SHALL be done via the dynamic
discovery procedure of the Address Resolution Protocol (ARP) [3].
The configuration of static mapping or the treatment of ARP within an
LIS supporting only PVC's is beyond the scope of this document.
Internet addresses are assigned independent of ATM addresses. Each
host implementation MUST know its own internet and ATM address(es)
and respond to Address Resolution requests appropriately. Hosts MUST
also use ARP to map Internet addresses to ATM addresses when needed.
The ARP protocol has several fields that have the following format
and values:
Data:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type
ar$shln 8 bits Octet length of source hardware address (m)
ar$spln 8 bits Octet length of source protocol address (n)
ar$op 16 bits Operation code (request or reply)
ar$thln 8 bits Octet length of target hardware address (p)
ar$tpln 8 bits Octet length of target protocol address (q)
ar$sha moctets source hardware address
ar$spa noctets source protocol address
ar$tha poctets target hardware address
ar$tpa qoctets target protocol address
Where:
ar$hrd - assigned to NSAP address family and is dd decimal
(0x00nn) [4].
ar$pro - see Assigned Numbers for protocol type number for
the protocol using ARP. (IP is 0x0800).
ar$shln - length of the source hardware NSAP address length.
ar$spln - length in bytes of the source protocol address. For
IP ar$spln is 4.
ar$op - 1 for request and 2 for reply
ar$thln - length of the target hardware NSAP address length.
ar$tpln - length in bytes of the target protocol address. For
IP ar$tpln is 4.
ar$sha - source NSAP address.
Laubach [Page 8]
DRAFT Classical IP and ARP over ATM July 1993
ar$spa - source protocol address.
ar$tha - target NSAP address.
ar$tpa - target protocol address.
The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be
ATM-FORUM specified NSAP addresses [9].
The same NSAP encoding SHALL be used within an LIS and replies will
use the same encoding as queries. For example, NSAP's may encode IEEE
48-bit MAC addresses or may encode E.164 addresses. Within the LIS
either IEEE MAC or E.164 hardware addresses may be used but not both.
ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP
encapsulation. The format of the AAL5 CPCS-SDU payload field for
routed non-ISO PDU's is:
Payload Format for Routed non-ISO PDU's
+------------------------------+
| LLC 0xAA-AA-03 |
+------------------------------+
| OUI 0x00-00-00 |
+------------------------------+
| Ethertype 0x08-06 |
+------------------------------+
| |
| ARP Packet |
| |
+------------------------------+
The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a
SNAP header.
The OUI value of 0x00-00-00 (3 bytes) indicates that the following
two-bytes is an ethertype.
The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4].
The total size of the LLC/SNAP header is 8-bytes fixed length. This
aligns the start of the ARP packet on a 64-bit boundary relative to
the start of the AAL5 SDU.
The LLC/SNAP encapsulation for ARP presented here is consistent with
the treatment of multiprotocol encapsulation of IP over ATM AAL5 as
specified in [2] and in the format of ARP over IEEE 802 networks as
specified in [5].
Laubach [Page 9]
DRAFT Classical IP and ARP over ATM July 1993
Traditionally, ARP requests are broadcast to all directly connected
IP stations within a LIS. It is conceivable in the future that larger
scaled ATM networks may "broadcast" ARP requests to destinations
outside the originating LIS, perhaps even globally; issues raised by
broadcasting outside the LIS or by a global ARP mechanism are beyond
the scope of this document.
10. IP Broadcast Address
ATM hardware multicast service addressing is not yet a conformance
requirement of the ATM-FORUM. As such, there is no consistent
facility in local area network ATM switches for hardware multicast
addressing. Experimentation with ATM multicast addresses in the
Internet community however, must be supported. The ATM-FORUM does
specify point-to-point and point-to-multipoint addressing [9]. The
following scenarios apply to the multicast and non-multicast
situations:
1. ATM multicast available: if the switch fabric connecting the host
ATM interface supports multicast, then the Internet broadcast
address (the address on that network with a host part of all
binary ones) MUST map to an ATM group address that includes all
IP stations within the LIS.
2. No ATM multicast support: the Internet broadcast address MUST map
to atm$arp-req, and atm$arp-req MUST either map to the local IP
host ATM hardware address or the ATM hardware address of an ARP
server located within the LIS, if available. If the LIS is
operating in the ARP Server model, the station acting as the ARP
server must relay IP packets received on an ARP unicast query VC
onto the point-to-multipoint ARP reply VC.
In all cases, encapsulated IP packets sent to the IP broadcast
address may be received on the ARP query VC by any station. This
requires that IP packets sent to the IP broadcast address use
LLC/SNAP encoding and that all stations examine the value of
ethertype in the LLC/SNAP header and process IP versus ARP
accordingly on all packets received on this VC.
11. IP Multicast Address
IP multicast address mappings to ATM point-to-multipoint or group
addresses are not discussed in this memo.
12. Security
Security issues are not discussed in this memo.
Laubach [Page 10]
DRAFT Classical IP and ARP over ATM July 1993
This memo recognizes the future development of ATM and IP facilities
for authenticated call setup, authenticated end-to-end application
knowledge, and data encryption as being required services for
globally connected ATM networks. These future security facilities and
their use by IP networks are beyond the scope of this document.
13. Open Issues
There are some open issues:
o A proposal was put before the Internet Assigned Numbers Authority
to approve a request to create an ARP hardware type of "NSAP
family address". IANA has not responded as of this date. My
hopes are that we can get an ARP type created now that will cover
NSAP's for all time.
o Well known ATM hardware address(es) for ARP servers? It would be
very handy if we came up with a set of well known ATM addresses
for ARP services. We should probably have well-known PVC numbers
for a non-SVC environment also.
o Interim Local Management Interface (ILMI) services will not be
generally implemented by some providers and vendors and will not
be used to obtain the ATM address network prefix from the
network. Meta-signalling does provide some of this functionality
and in the future we need to document the options.
REFERENCES
[1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS
Service", RFC1209, USC/Information Sciences Institute, March
1991.
[2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", work in progress, IETF IP over ATM Working Group,
February 1993.
[3] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48.bit Ethernet Address for
Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
[4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/
Information Sciences Institute, July 1992.
[5] Postel, J., and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information
Sciences Institute, February 1988.
Laubach [Page 11]
DRAFT Classical IP and ARP over ATM July 1993
[6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII,
Geneva, 19-29 January 1993.
[7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September
- 2 October 1992.
[8] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC1122, USC/Information Sciences Institute, October
1989.
[9] ATM-FORUM, "ATM User-Network Interface Specification Version 3.0.
(DRAFT)", June 1993.
Author's Address
Mark Laubach
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
Phone: 415.857.3513 FAX: 415.857.8526
EMail: laubach@hpl.hp.com
Laubach [Page 12]